1. Field of the Invention
This invention relates generally to host operating systems that support multiple virtual machines and, more particularly, to monitoring the status of control data structures maintained both by host operating systems and guest operating systems or guest applications.
2. Description of the Related Art
Users communicate with a computer processor through an interface known as an operating system. Through the operating system, the users control the processor to manipulate data and initiate input and output operations. A set of address locations in memory of the processor defines the execution space under control of the operating system, which is where the operating system program code, system data, pointers to instruction addresses, control data structures, and the like are kept. Depending on the processor model and the operating system, a user can designate one or more virtual machines that will be supported by the operating system. The operating system will maintain a separate set of pointers, control data structures, and the like to support the activities of the virtual machine.
As an example, the International Business Machines Corporation ("IBM") operating system known as "Virtual Machine Enterprise Systems Architecture (VM/ESA)" supports multiple virtual machines. Each virtual machine is a functional equivalent to a real machine. Each of the virtual machines supported by the host processor is referred to as a "VM" and the underlying host processor operating system that manages the VM is generally referred to as a control program, or "CP" in the IBM nomenclature. It is the function of the CP to control operations in the host processing environment, including management of system resources, establishment of the virtual machine environment, and isolation of the various virtual machine owned storage areas from each other.
Main storage is allocated in extents known as absolute-storage address spaces, or simply address spaces. When a virtual machine is created by the host, an initial address space is provided for the virtual machine. This address space is known as the host-primary address space. The host operating system manages the virtual machines and the users such that a user running a virtual machine is restricted from gaining access to the address/data spaces of any other virtual machine. Initially, the host-primary address space is directly addressable only by the CPUs of the associated virtual machine. However, by using host services, the main storage (host-primary address space) of one virtual machine can be made directly addressable by the CPUs of another virtual machine. This shared main storage can be used to provide shared data for a collection of virtual machines executing on a single VM/ESA system.
Control of the host computer processor can be passed to a virtual machine whereby the user can interact through a virtual machine operating system interface that permits the user to manipulate data and initiate input and output operations. In this environment it appears to the user that it is executing on, and has full control of, the entire real processor complex. Thus, it is indistinguishable to the user whether it is conducting data operations in the execution space through the host computer or in the execution space of a virtual machine supported by the host computer. Thus the presence of multiple virtual machines supported by a single host computer processor is transparent to the users.
In a VM/ESA system, virtual machines can simulate the IBM System/370, 370-XA, ESA/370, and ESA/390 functions. In addition, on ESA/390 systems, an XC virtual machine architecture is available. An XC-mode virtual machine configuration contains all of the basic organizational elements defined for ESA/390 systems: main storage, one or more central processing units (CPUs), operator facilities, a channel subsystem, and I/O devices. In addition, an ESA/XC configuration has available additional separate absolute-storage address spaces, up to fifteen of which are concurrently addressable as provided by access-register addressing. These fifteen absolute-storage address spaces are selected from among a larger set as determined by a table called a host access list.
An access register contains an indirect specification of an absolute-storage address space. Each access register can designate any address space, including the instruction space (the host-primary address space) of the owning virtual machine or, if so permitted, another virtual machine. When one of the access registers is used to designate an address space, the CPU determines which address space is designated by translating the contents of the access register using host-managed tables.
An ESA/XC virtual machine has a host access list that specifies the set of address lo spaces, in addition to the virtual machine's host-primary address space, that are available to a CPU when it is in the access-register mode. The host access list contains a directory-specified number of host access-list entries, each of which either designates a particular address space or is considered unused. An access-list entry token (called an "ALET") corresponds to an address space of a VM. Through the use of host services, a host access-list-entry can be set to designate a particular address space or can be returned to the unused state.
A virtual machine host-primary address space can be loaded with and can execute, within the bounds of that virtual machine, another guest operating system. In a VM/ESA system, the CP supports an Initial Program Load "IPL" command through which a virtual machine user can o designate a guest operating system that will begin executing within the VM's host-primary address space. That is, a user running a VM can bring up a new operating system, thus the concept of running a guest operating system. Any user running on this new guest system can, in turn, bring up another operating system with yet additional VMs. In this way, the virtual machine environment permits many different operating systems to exist simultaneously and automatically provides independent operation to ensure data integrity and security.
When a VM is running a guest operating system, the host primary address space of that VM contains the numerous control data structures of the guest operating system used to support and maintain the running of the VMs executing on the new system. These control data structures include, for example, memory, hardware configuration information, program queues, input/output activity, counters that indicate relative position in operating queues, and the like. These are the same type of control and data structures that are being maintained by the host operating system that is supporting the VM that is running the new operating system.
It is convenient for a user having operational responsibility to run monitoring programs that retrieve the status of such control structures, thereby providing the user with the ability to check system performance and, if necessary, plan and implement changes in systems operations for greater efficiency or to validate that specific system control structures are being maintained correctly, possibly after an operating system code change has been made.
Typically, a system monitoring program that will retrieve the status of control data structures of an operating system, that is running in a VM, must run on the guest operating system running in that same VM. Unfortunately, the monitoring program itself usually has an influence on the system it is monitoring. That is, the monitoring program comprises an active program of the VM and will be associated with user identification data, the monitoring program will occupy locations in operating queues, and the monitoring program will compete for VM resources along with all the other programs being run by other users. In addition, the performance of the monitoring program itself is affected by the performance of the VM. For example, if the VM is heavily loaded and is operating relatively slowly, then the monitoring program also will operate relatively slowly. Thus, the performance and usefulness o of a monitoring program can be compromised by the requirement of running in the monitored VM. Another factor to be considered is that the monitor program must be written specifically to the interface of the guest operating system under test if it is to run on that system. Therefore, operating system-specific monitoring programs must be written and maintained.
It is known to gain access to the address/data space of another VM by using the access-list-entry token (ALET). As noted above, the ALET ordinarily specifies an address/data space associated with a VM. The ALET, however, also can be used to specify spaces associated with other VMs, thus a user can directly address another VM's address/data space. In this way, it is possible to monitor the operation of one virtual machine from another without affecting the operation of the monitored virtual machine. A method for obtaining such access is described, for example, in U.S. Pat. No. 5,230,069 to Brelsford et al., which is assigned to the assignee of this application and is incorporated herein by this reference.
If a VM user issues an IPL command to the CP to bring up another operating system, then the CP automatically revokes all access to any previously permitted spaces. That is, the storage that was previously accessible before the IPL command is no longer shared. Consequently, if a VM being monitored issues an IPL command, then the monitoring VM no longer has access to the data control structures of the operating system that are maintained in the host-primary address space of the VM who issued the IPL command. It should be noted that there is no supported conventional interface to establish, in the first place, a shared host-primary address space once the VM uses the IPL command to invoke another operating system such as VM/ESA.
In addition, the ALET scheme of gaining access to the address/data space of a VM does not support gaining access to the execution space of the host processor itself. The data structures defining the host processor execution space are maintained in the same manner as the data structures that define a VM's host-primary address space, but services are not provided for a user to access the host execution address space. It would be advantageous if a user running on a host processor could gain access to the execution space control data structures to perform a monitoring function of the host operating system.
From the discussion above, it should be apparent that there is a need for an apparatus and method that permits access and monitoring capability of control dam structure locations in a plurality of virtual machines from a given one of the virtual machines without substantially effecting the operation of the host computer or the virtual machine being monitored. It should also be apparent that there is a need to perform this same method of monitoring of the host operating system. The present invention satisfies these needs.